For many online services, users are required to first establish an account with the provider of the services. Depending on the service, the account may be paid or free. After a user establishes an account with a service, the service must verify that the user is associated with the account each time the user establishes a session with the service. The process of verifying that a user is associated with an authorized account is referred to as “user authentication”.
One common way for a service to authenticate a user is to require that the user provide a username/password combination at the time the account is created. In future sessions, the user provides the username/password combination to the service at the beginning of each session to verify that the user has the account. The term “native authentication” is used herein to refer to a service that authenticates users without involving third-party authentication services.
Many users have accounts with multiple online services, each of which may require a username/password. In order to remember their passwords, users may write them down, use the same password for all services, or pick easy-to-guess passwords. Unfortunately, all of these practices compromise the security the use of passwords is intended to promote.
To address the difficulty of remembering distinct, hard-to-guess passwords for multiple services, some services have been developed whose purpose is to assist with the authentication of other services. Such services, are referred to herein as “single-sign-on providers”. In general, single-sign-on allows a user to log in once, and thereby gain access to multiple services without being prompted to log in again to each of them.
Various approaches have been taken to provide single-sign-on functionality. Such approaches include Kerberos based single-sign-on, smart card based single-sign-on, Integrated Windows Authentication, and Security Assertion Markup Language (SAML), which is an XML-based solution for exchanging user security information between an enterprise and a service provider. These are merely examples of single-sign-on approaches, and the techniques described herein are not limited to any particular approach for single-sign-on.
Though single-sign-on providers are generally available, it is common for many users of a service to use the native authentication of the service, rather than a single-sign-on provider. For example, a user or company that uses few services may not think the cost of using a single-sign-on provider is justified. Therefore, many services need to have support for both native authentication and single-sign-on authentication. In systems that support both native authentication and single-sign-on authentication, it is important to provide tools that assist administrators in the management of the authentication options.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.